A conventional client/server system may receive data from multiple internal and external sources and may provide various methods for receiving such data. For example, software applications or program objects may be implemented to act as listening devices or message endpoints. A server may establish a resource adapter for the purpose of receiving messages from a particular enterprise information system (EIS), with messages from the EIS being transferred through the resource adapter and then being directed to the appropriate listening devices.
A conventional client/server system may impose limitations on the types of application or objects that can act as listening devices for a server. For example, in a J2EE environment, a message endpoint for asynchronous receipt of messages is limited to a message-driven enterprise Java bean (MDB). Other types of components cannot be utilized to consume such messages.
In addition, a conventional client/server system may be inefficient in the establishment of a messaging subscription. Such a process requires that certain choices be made because, for example, a system component is likely only compatible with certain message types, a resource adapter is not generally compatible with all message providers, and a resource adapter will only support certain message types. Further, when a message subscription is activated, certain compatible resource adapters may potentially already be in place during the negotiation of the subscription, but such existing adapters will not be utilized if their existence is not discovered. Similarly, the deactivation of resources will not be efficient if the message endpoints and resource adapters are not sufficiently identified in the process.